Turnbull China Bikeride

home *** CD-ROM | disk | FTP | other *** search

/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 1.iso / HENSA / MISC / UNIMODE / UNIMODE.ARC / !UniMode2_Manuals_UserGuide < prev next >

Wrap

Text File | 1994-06-09 | 34.0 KB | 876 lines

User's Guide Contents ~~~~~~~~~~~~~~~~~~~~~ Terminology Description of the application Using UniMode2 UniversalMode module and Enhancer states Getting information on modes (ModeInfo & TimeRaster) Extracting modes Editing a definition Compiling modes Saving MDFs and MDSs Loading modes Terminology =========== The following terms are introduced with this package: MDF or ModeDescriptionFile : This is a file with the - Acorn approved - filetype &103. The VIDC- and Workspacelists of a mode are stored in this file together with some machine specific data. The UniversalMode module loads this file when you use the ModeLoad command. An MDF can be recognized by it's icon and the FileType: UniMode (&103). MDS or ModeDescriptionScript : This is a textfile. This file contains all the information of the corresponding MDF in ASCII-format. This file can be edited to change certain parameters or variables. After that you can compile the MDS into an MDF. If you are going to edit the MDS, be warned that if you do not know anything about programming the VIDC you may not like the result of your venture. With UniMode2 the MDS has become somewhat obsolete since you can now edit a modedefinition from the windows-contents. VIDC Enhancer-Add-On: With this is meant the third party products generally known as the "VIDC Enhancer" which are available for 300/3000/400 series of machines from several companies. On-Board-Enhancer: With this we mean the Enhancer-hardware built-in by Acorn in the 500/5000 series and (probably) future machines. VidcEnhancer: The term VidcEnhancer is used to refer to both the VIDC Enhancer-Add-On and the On-Board-Enhancer. Soft-mode There are RISC OS modes and soft-modes. RISC OS modes are supplied by RISC OS itself. Soft-modes are supplied by RAM-modules or other applications. The term "Soft" refers to the fact that they are not in ROM. Description of the application ============================== Read the file 'Install' for guidelines on installing your copy of !UniMode2 on your system. After you have installed it double-clicking on the !UniMode2-icon will install the application on the icon bar. The application supports Acorn's Interactive Help. Shift-Double-click will open the application directory and reveal the following sub-directories: <UniMode$Dir>.Manuals contains this manual. <UniMode$Dir>.Modes contains any MDFs that you have compiled or extracted. <UniMode$Dir>.ModeScript contains the script files. <UniMode$Dir>.Resources contains the various utilities supplied with the package. If you start the application it will install itself onto the icon bar. Clicking SELECT over the icon bar icon will open the directory <UniModeMDF$Dir>. This directory contains the available ModeDescriptionFiles (MDF). Clicking ADJUST over the icon bar icon will open the directory <UniModeMDS$Dir>. This directory contains the ModeDescriptionScripts (MDS). Clicking MENU over the icon bar icon opens the application's menu. The menu supplies the following options: Info ⇨ Edit ⇨ Save ⇨ ModeInfo Enhancer ⇨ TimeRaster Compile Extract ⇨ Quit * Choosing 'Quit' will remove the application from the icon bar. However, the module and all mode definitions that have been loaded remain active until you RMKill the module, switch off the machine or use *ModeClear to remove a specific mode. * 'Extract ⇨' leads to a dialogue box. The dialogue box contains 127 numbered icons each representing one screenmode. A row of radio buttons allows you to select a MonitorType. The large "Scan Modes" button allows you to rescan the system to see if any new modes have been installed. Refer to the chapter "Extracting modes" below for more information. * Choosing 'Compile' will compile the MDF as it is defined in the windows. A short log will be displayed. Refer to the chapter "Compiling modes" below for more information. * 'TimeRaster' displays the rastertime and rasterfrequency of the current mode. * 'Enhancer ⇨' leads to a sub-menu with the options On, Off, Auto, Intelligent, Prefs and Quiet. Clicking on one of these options switches the UniMode module in the corresponding state. The current state of the module is reflected in the menu with a tick-mark. The state of the VidcEnhancer is reflected through the last option in this menu. If the VidcEnhancer is switched on by the module; the menu-item reads: 'Status: On'. If the VidcEnhancer is switched off by the module then the menu-item reads: 'Status: Off'. If the module is switched into its Quiet mode the status of the VidcEnhancer is controlled by other software and hence is unknown to the module. This is shown by the last menu-item as: 'Status: ???'. When the module doesn't know the state of the enhancer but isn't switched into 'Quiet' mode the item will read 'Status: Unk'. Refer to the chapter entitled "UniversalMode module and Enhancer states" for more details. * Choosing 'ModeInfo' will display some vital information of the modes currently installed. * 'Save ⇨' leads to a submenu containing the items "MDF" and "Script". Both items lead to a save-box allowing you to save the corresponding MDF or MDS. Refer to the chapter "Saving MDFs and MDSs" for more information. * 'Edit ⇨' leads to a submenu containing the items "Specs...", "VidcRegs...", "ModeVars..." and "ID Text...". Choosing one of these items opens a corresponding window which allows you to alter specific characteristics of the mode under design. Refer to the chapter "Editing a definition" for more information. * 'Info ⇨' leads to a standard information window. Using UniMode2 ============== Contents: UniversalMode module and Enhancer states Getting information on modes (ModeInfo & TimeRaster) Extracting modes Editing a definition Compiling modes Saving MDFs and MDSs Loading modes Universal Mode module and Enhancer states ----------------------------------------- Before you are able to make your modes with UniMode2 you will need to know how the package works. The core of the package is the relocatable UniversalMode module. This module provides all the interfaces with the operating system. The most important reason to write this module, was to gain full control over the VidcEnhancer, and getting rid of the "AutoVidc" program which was only partly a solution to the problems. You might look at the !UniMode2-package as an upgrade from "AutoVidc". The module provides 5 ways in controlling the VidcEnhancer: *Vidc On This command switches the VidcEnhancer on (36 MHz). The pixelrate of any mode is increased to 1.5 times of the default rate. This means that normal B(roadcast)S(tandard)-modes become real calm (50 -> 75 Hz). Or you can use much bigger modes at a respectable rasterfrequency. *Vidc Off This command switches the VidcEnhancer off. *Vidc Auto This command was implemented to emulate the SuperVidc Auto command and the AutoVidc control. Where SuperVidc uses a triggerlevel, or AutoVidc uses an internal table to determine whether the VidcEnhancer should be switched on or off, the module uses the VidcEnhancerbit in an MDF. Modes which are generated using Unimode2 can be programmed to switch the VidcEnhancer on or off (for details see the description on making an MDS). For standard RISC OS modes, you can load a "VidcOn" or a "VidcOff"-file on that mode. Example: if you want the VidcEnhancer to be switched on when entering mode 12 just type *Modeload VidcOn 12. One minor set-back is that the VidcEnhancer will only be switched off if a "VidcOff" was loaded for another mode, or a *Vidc Off command is issued otherwise it will remain on after a modechange. *Vidc Intelligent This command switches the module to its "Intelligent" state. This means that a very complex algorithm is used, every time you select another mode, to determine whether the VidcEnhancer should be switched on or off. We have not (yet) found any mode that is judged incorrectly by the algorithm. This is also the default state. *Vidc Prefs *Vidc Prefs is a combination of all goodies, especially included for those who CAN get the Intelligent algorithm to fail. In this state the action taken by the module is modenumber-dependent: RISC OS 3 modes are switched on according to our own preferences. All other modes under 96 will act as if the module is in its Intelligent-state. Modes from 96 to 111 will act as if the module is in its Auto-state. Modes from 112 to 119 will switch the VidcEnhancer on, the remaining modes from 120 to 127 will switch it off. *Vidc Quiet This command switches the module to its "Quiet" state. This means that the module will not affect the state of the VidcEnhancer. This allows other soft- or hardware to affect the state of the VidcEnhancer. A little feedback from the module to the user might come in handy if you are busy programming MDF's. So the *Vidc Status command was included to return some information on the module- and VidcEnhancer-state. Concerning modes, RISC OS 3 has one shortcomings, there is no command provided to set the mode used by the operating system. That is, until now; as it was implemented in the module: *Mode <mode#> Sets a new screen mode. Eg.: *mode 12 All you need to do, to use a soft-mode, is loading a ModeDescriptionFile (MDF) in the workspace of the module at the modenumber you want. This can be done by using the command: *ModeLoad <filename> <mode#> To remove a modedefinition from the list can be done by using the command: *ModeClear <Mode#> The mode <Mode#> will no longer be available from this module. To see a list of the currently installed modes use the utility 'ModeInfo'. NOTE: You can load an MDF at a modenumber which is already provided by RISC OS itself under certain circumstances. Such an MDF is called an 'Overlay'. Refer to the file: 'Hints and Tips' for more details. *HardwareRevision [<Revision#>] makes it possible to set the HardwareRevision manually in case the determination algorithm used in this module fails. Revision Enhancer type ------------------------------------------------- 0 Atomwide compatible (IO1) 1 Acorn On-Board (eg. A540 A5000) 2 SPEM compatible enhancer, mapped at IO1 3 Atomwide compatible (IO2) *HardwareRevision without a parameter echoes the current HardwareRevision set. *VidcThreshold [<high> [<low>]] Refer to the file: 'Conversion'. <high> and <low> represent rastertimes in µs while the VidcEnhancer is switched off. This command controls the switching of the VidcEnhancer state. When the rastertime drops below <high> the VidcEnhancer will be switched on. When the rastertime becomes less than <low> the VidcEnhancer will be switched off. Normally the default values won't need to be changed. Summary of Commands Syntax: *ModeLoad <FileName> <Mode#> *ModeClear <Mode#> *Mode [<Mode#>]> *VIDC On|Off|Auto|Prefs|Intelligent|Quiet|Status (Default: Intelligent) *HardwareRevision [<Revision#>] *VidcThreshold [<high> [<low>]] (Default: high=20016; low=3632) NOTE Because we did not know how to interface with the Watford-compatible VidcEnhancer, this VidcEnhancer is not supported. If YOU do know how to do this let us know so that we can update the software. Getting information on modes (ModeInfo & TimeRaster) ---------------------------------------------------- With UniMode2 come two small utilities. They can be found in the directory 'Resources'. TimeRaster displays the RasterFrequency of the current mode. A similar function is available from the UniMode2 main menu. Choosing 'TimeRaster' will display the RasterFrequency (in Hz) and the RasterTime (in µs). When you choose 'ModeInfo' from the UniMode2 menu ModeInfo is run in a TaskWindow. 'ModeInfo' gives some basic information about the modes that you have currently available through RISC OS; loaded into UniMode; or supplied by other modules. When run from the CLI you have some extra options *ModeInfo [<Mode#>|-t] With no parameters ModeInfo will return the information of all modes currently installed. If you supply a number in the range 0...127 the information (if any) of that mode only is given. Alternatively using the -t switch will give you the information on the current ('t'his) mode. The following information is supplied: - Modenumber - Text: number of columns times number of rows - Graphics: number of X-pixels times number of Y-pixels - OS: number of OS-pixels in X- and Y-direction - Colours: number of colours - Memory: amount of screenmemory required - Type: OS: RISC OS mode; Uni: UniMode mode; Sft: mode supplied by other module. In case of Uni the ID text is also displayed. Extracting modes ---------------- When you want to define a working screenmode, starting from scratch is very difficult if not impossible. Therefore you are advised to base your mode on an existing modedefinition. This can be a RISC OS mode or an existing soft-mode. In the main menu the item 'Extract' leads to a dialogue window. At the right-hand side of the window there is a list of the monitortypes supported by UniMode2. You start by selecting the monitortype for which you want to design a mode. UniMode2 will (at startup) automagically select the type of monitor currently configured/connected. To the left are 128 icons numbered 0...127. Each icon represents a screenmode. The colour code is defined as follows: Grey Does not exist Black RISC OS mode (Acorn) Green UniMode2 mode Red Screenmode supplied by other source. The colour of the icons is defined when UniMode2 is started up. If there are any changes after that (loading new screenmode-definitions or modules) simply press the 'Scan Modes' button. When you click on one of the icons UniMode2 will attempt to extract the corresponding mode. The definition of the mode can then be edited or directly compiled and saved. Where possible you should try to get rid of the red icons. If you do this you will find that you are saving a considerable amount of memory. There is a very simple procedure to do this. For every red icon do the following: 1. Extract the mode into UniMode2 2. Compile the mode 3. Save the MDF to a file 4. Next time instead of loading the module that supplied this mode: load the MDF. You can achieve this simply by replacing the *RMLoad <module> command in the appropriate !Boot or !Run file by a *ModeLoad <MDFfile> <Mode#> for each extracted mode. Ofcourse you don't have to *ModeLoad all those MDFs. If there are modes that you never use you can save memory by not loading their definition at all. Or only when you need it. Editing a definition -------------------- Once extracted you may want to adjust the mode. Tailor it to the specific characteristics of your monitor. For this there are four windows which can be accessed via the 'Edit ⇨' option in the main menu: o Specs... This lets you select the prefered VidcEnhancer state (On or Off) when the UniMode state is Auto (Achieved by *Vidc Auto). Additionally you can select for which monitortype this mode should be available. (NOTE: This does not mean that the mode will automatically work properly on that monitortype! Usually you'll just need to specify your own monitortype). o ID Text... In the ID Text window you can enter some copyright text and most of all some mode information. The utility ModeInfo displays this information as does UniMode when ever you load a MDF. o VidcRegs... In this window you can alter the contents of the various Vidc Registers. The Vidc Registers are programmed into the Vidc when this mode is selected. For more detailed information you should consult the file 'PRM'. o ModeVars... In this window you can alter the ModeVariables. The ModeVariables are used by RISC OS to display everything correctly on the screen. For more detailed information you should consult the file 'PRM'. If you actually want to start designing a new mode. Be warned: it's not easy. Read the file 'PRM' and if possible some other documentation about the VIDC. Compiling modes --------------- Saving MDFs and MDSs -------------------- Loading modes ------------- @ CompileMDS ---------- { <UniMode$Dir>.Utils } This program compiles an MDS into an MDF. For safety reasons, you can only compile one file at a time. There are two ways of compiling an MDS. The first one is discussed in the paragraph '!UniMode'. The second way of compiling an MDS is via the CLI: SYNTAX: *CompileMDS [<Inputfile> [<Outputfile> [<Logfile>]]] INPUT: Input file : This is the filename of the MDS. The directory is assumed to be the standard directory where all script files are stored: <UniModeMDS$Dir>. Output file : This is the filename of the MDF. The directory is assumed to be the standard directory where all definition-files are stored: <UniModeMDF$Dir>. Run-time logging: CompileMDS reports on virtually everything it is doing (including any anomalies or errors that are encountered). You can redirect this output to virtually any destination (E.g.: null:, vdu:, printer:, serial:, ram:logfile, adfs::0.$.logfile, etc.) Remember that the destination must exist. Sending the logfile to a (non-existent) serial: device can lock the machine. OUTPUT: The program outputs a log to the specified file/device and an MDF to the specified path/filename. NOTE: * The program does NOT check whether an MDF already exists. * An MDS is compiled in four passes. During the first pass the compiler checks the MDS for spelling mistakes. An error during this pass generally means a spelling mistake in one of the variablenames or in either card. Refer to the log to see where the mistake occurred. During the second pass the compiler will attempt to evaluate the value assigned to each variable. At the same time it will check whether the variable is valid. For example HDSR is a VIDC register. It can only occur in .VIDClist. If you would include this variable in .WorkspaceList the compiler would generate an error. Pass 3 is used to evaluate all the values and assign them to the appropriate variable ready for compilation. During this pass the compiler will report which variables will be programmed with which value. The third pass is also used to do a so-called "Cross-check". During the cross-check the compiler tries to find out whether the MDF being created COULD result in a working mode or not. Any warnings generated during the cross-check MIGHT indicate that the defined mode will not give a satisfiable display on your monitor. The compiler will also try to calculate the mode's rasterfrequency. This may deviate from the measured rasterfrequency by ± 2Hz. Refer to your monitor's manual to see if this mode can be displayed on your monitor. (Look in the technical specifications for "Vertical Sync", "Vertical Synchronisation", "Raster Frequency" or something similar. Typical values will be in a range between 50...100 Hz) Finally the HB_Index of the mode is calculated. Refer to the chapter 'HB_Index' for more details. The final pass (Pass 4) is the compilation pass. All that happens here is the creation of the MDF from the results of the previous passes. * If the Logfile is set to null: then errors and warnings are reported to you through a standard text-window (provided that you're compiling from the desktop). If the Logfile is set to anything else the errors or warnings are put in the log. The compiler will display a message that an error or warning has occurred and refer you to the log. Expand / ExpandAll ------------------ { <UniMode$Dir>.Utils } These programs are used to convert an MDF into an MDS. The functional difference between the two is that 'Expand' operates on one file at a time while 'ExpandAll' operates on an entire directory. You can optionally supply the required parameters at the commandline. SYNTAX: *Expand [<Inputfile> [<Outputfile>]] *ExpandAll [<SourcePath> [<DestinationPath>]] INPUT: Input file : This is the name of the MDF. The directory is assumed to be the standard directory where all definition-files are located: <UniModeMDF$Dir>. Output file : This is the name of the MDS. The directory is assumed to be the standard directory where all script files are located: <UniModeMDS$Dir>. Source Path : This is the name of the path where the MDF-s can be found. This is <UniModeMDF$Dir>. by default. Destination Path: This is the name of the path where the MDS-s must be stored. This is <UniModeMDS$Dir>. by default. OUTPUT: The programs output the appropriate MDS(-s) to the specified path/filename. NOTE: * 'ExpandAll' is recursive, i.e. it will also expand files in directories inside the one you dragged to the Input window. * 'Expand' can also be accessed by clicking 'Expand' in the !UniMode menu on the desktop. Refer to the paragraph '!UniMode' for more details. Extract / ExtractAll -------------------- { <UniMode$Dir>.Utils } These programs can be used to extract the mode definitions from a RAM-based module (including UniMode) and thus create an MDF. Since copyright laws apply to some of these mode definitions, you may extract them for use in your OWN version of UniversalMode, but you may not pass these MDF-s to others. It is not necessary to disassemble a mode-supplying module. By simply calling OS_ServiceCall &50 'Extract' and 'ExtractAll' can find out all that is needed to know about a given mode in order to compile an MDF. The functional difference between these two programs is that 'Extract' extracts one mode at a time while 'ExtractAll' extracts all modes defined by RAM-based modules. You can optionally supply the required parameters at the commandline. SYNTAX: *Extract [<Modenumber> [<Outputfile>]] *ExtractAll [<CommonPart> [Q|S]] INPUT: 'Extract' displays the available modes. Type in the number of the mode that you wish to extract. You are offered a path/filename which you can change to your own liking. 'ExtractAll' displays the available modes. You need to enter the common part of the path/file-name. 'ExtractAll' appends the modenumber to this name and saves the MDF-s. (E.g. if the modes 50, 51 and 52 are available and the common part is specified as 'm'. Then the modes are saved as 'm50', 'm51' and 'm52') 'ExtractAll' lets you choose whether to "(Q)uery each" or "(S)ave all". Enter 'Q' and the program will let you change the filename before saving it. Delete the filename and that mode will be skipped. Enter 'S' and all modes will be extracted. OUTPUT: Both programs store the MDF-s at the specified path/filename. NOTE: * RISC OS modes can not be extracted, because the UtilityModule does not reply to OS_ServiceCall &50 and no other means of retrieving this data is supplied by RISC OS. * Both 'Extract' and 'ExtractAll' also extract the soft-modes loaded by UniMode. If you do not want this to happen, you should enter *RMKill UniversalMode before starting either of these programs. * 'Extract' and 'ExtractAll' create a MDS with the following MachineSpecs by default: .MachineSpecs VidcOn MultiScan ExtractOS2 / ExtractOS3 ----------------------- { <UniMode$Dir>.Utils } As mentioned above, RISC OS modes can not be extracted by 'Extract(All)'. In some circumstances, however, you need the contents of the RISC OS registers in order to make a working MDF. For instance: If you want to use an MDF based on a RISC OS 3 BaseMode on a RISC OS 2 machine, you have got a problem. The best way around this, is to set BaseMode to the nearest RISC OS 2 BaseMode and then define ALL VIDC registers with the RISC OS 3 values. Using 'ExtractOSn': 1. Create a RAM-disc of at least 112k. 2. Create a directory 'Modes' on the RAM-disc. 3. Create a directory 'ModeScript' on the RAM-disc. 4. a. On a RISC OS 2 machine run the program 'ExtractOS2' b. On a RISC OS 3 machine run the program 'ExtractOS3' 5. The RAM-disc now contains the MDF's and MDS's of the OS-modes. (All MDF's are automatically expanded using 'ExpandAll' Since distribution of these definitions may violate Acorn's copyright we have not included the RISC OS MDF's in the package. INPUT: - OUTPUT: These programs create MDF's of RISC OS modes. The MDF's are stored on the RAM-disc. The program 'ExpandAll' is called to create the MDS's. NOTE: * The presence of the directories 'Modes' and 'ModeScript' on the RAM-disc is assumed. * It should be obvious that 'ExtractOS2' cannot be used on a RISC OS 3 machine and vv. * It is very likely that 'ExtractOS3' only works on A5000 machines and not on other machines running RISC OS 3. * It is also very likely that 'ExtractOS2' and 'ExtractOS3' do not work on an A540 (different OS versions). We haven't tested this so if you have an A540, let us know! InfoMDF ------- { <UniMode$Dir>.Utils } 'InfoMDF' gives information about a given MDF. SYNTAX: *InfoMDF [<Inputfile>] INPUT: Mode file : This is the name of the MDF. The directory is assumed to be the standard directory where all definition-files are located: <UniModeMDF$Dir>. OUTPUT: Displays some information about the modedefinition. Depending upon the values stored in the MDF different information may be given. One or more of the following items may be included in the output: Item Description ----------------------------------------------------------------------------- 'Auto'-mode VidcEnhancer : When UniMode is in the 'Auto'-mode the VidcEnhancer will be switched to this state. (ON|OFF) BaseMode used : The modenumber of the BaseMode that has been defined in '.VIDCList' and '.WorkspaceList'. If the BaseMode defined in '.WorkspaceList' differs from the one defined in '.VIDCList' then both BaseModes are specified : <VidcList> [/ <WorkspaceList>] Monitors supported : This item lists all the monitortypes for which this MDF is valid. Rasterfrequency : The rasterfrequency of the mode when the VidcEnhancer is switched to its 'Auto'-mode setting followed by the rasterfrequency of the mode when the VidcEnhancer is switched to the opposite state between brackets. Linefrequency : The linefrequency of the mode when the VidcEnhancer is switched to its 'Auto'-mode setting followed by the linefrequency of the mode when the VidcEnhancer is switched to the opposite state between brackets. Broadcaststandard : The utility evaluates whether the mode can be used as a BroadcastStandardMode or not. If it can't be used as a BSDM in its 'Auto'-mode setting then the result will be "NO". If it can be used as a BSDM in its 'Auto'-mode setting then the result will be "YES". The result will be "(YES)" if the mode can be used as a BSDM when the VidcEnhancer is switched to the opposite state of the mode's 'Auto'-mode setting. Number of characters per line: Obviously, the number of characters/line Number of lines : The number of textlines in the display. X resolution : The number of horizontal pixels. Y resolution : The number of vertical pixels in the display Number of colours : The number of colours that can be displayed. X-eigenfactor : Refer to the Programmer's Guide. Section: "Mode Variables". The description of the variable 'XEigFactor' Y-eigenfactor : Refer to the Programmer's Guide. Section: "Mode Variables". The description of the variable 'YEigFactor' Screenbuffer size : The number kbytes of screenmemory required. ModeFlags : Each bit in the 'ModeFlags' variable is displayed here if it is set. Refer to the Programmer's Guide; Section: "Mode Variables". The description of the variable 'ModeFlags'. NOTE: 'InfoMDF' can also be accessed through the desktop front-end. Refer to the paragraph called "!UniMode" for more details. ModeInfo -------- { <UniMode$Dir>.Utils } 'ModeInfo' gives some basic information about the modes that you have currently available through RISC OS; loaded into UniMode; or supplied by other modules. SYNTAX: *ModeInfo [<Mode#>] INPUT: - OUTPUT: With no parameters ModeInfo will return the information of all modes currently installed. If you supply a number in the range 0...127 the information (if any) of that mode only is given. The following information is supplied: - Modenumber - Text: number of columns by number of rows - Graphics: number of X-pixels by number of Y-pixels - OS: number of OS-pixels in X- and Y-direction - Colours: number of colours - Memory: amount of screenmemory required - Type: RISC OS mode or soft-mode UMUserLib --------- { <UniMode$Dir>.Utils } 'UMUserLib' is a library. It is linked into 'Expand(All)' and 'CompileMDS'. The library contains a number of functions. These functions can be used in the definition of the MDF as substitutes for numerical values. See the Programmer's Guide for more details. UniModeLib ---------- { <UniMode$Dir>.Utils } 'UniModeLib' is also a library. It is linked into all utilities including the !RunImage. This library supplies the shared resources for the programs in the package. The contents of this library should not be altered by the user. If you wish to add FuNctions or PROCedures you should add them to 'UMUserLib' instead. TimeRaster ---------- { <UniMode$Dir>.Utils } This Utility can be used to measure the rasterfrequency of the current mode. The result may deviate ± 2Hz from what is calculated by CompileMDS. This deviation is due to rounding differences. The HB_Index ============ The HB_Index is a number which gives a rough indication of the redraw-speed of a mode. The HB_Index is calculated as follows: 1000 1) R = --------------- Rasterfrequency (bpp * (XWindLimit+1) * (YWindLimit+1) * 1000) 2) M = ---------------------------------------------- 8 M 4E7 - --- R 3) HB_Index = ----------- 4E7 The result is a number between 0.00 and 1.00. A low number typically means a slow mode, while a higher number suggests a faster mode. The redraw-speed of a mode can be experienced if the WIMP has to redraw a complete screen - with many different windows overlapping each other - after eg. a mode change (Press F12 followed by [RETURN] to simulate a mode change). A slow mode will take a longer time to redraw the screen. As a result a fast mode indicates that the ARM has more time left to perform other operations. Generally you will want to perform time-expensive tasks such as printing etc. in a fast-mode. Eg. Mode 0 (which is often used for this purpose) has an HB_Index of approximately 0.97 while Mode 28 (clearly a slower mode) has an HB_Index of 0.55. The HB_Index depends on the Rasterfrequency of the mode. Therefore the compiler calculates an HB_Index for the mode for both VidcEnhancer states. With the currently available hardware (ARM2/ARM3 and 8 or 12 MHz MEMC's) modes with an HB_Index higher than 0.55 are usually experienced as reasonably fast modes. Modes with an HB_Index lower than 0.45 will be experienced as slow.